![]() |
|||
![]()
|
![]() |
![]() Click Here! |
![]() |
Frame Relay Network-to-Network Interworking The maturity of frame relay as a service, and the experience gained by the vendors supporting the carriers offering service, has translated into the development and enhancement of frame relay network-to-network interface (NNI) standards. NNI defines the interface between networks, as opposed to the interface between user equipment and a network, and is a must for intercarrier service offerings. (An NNI Implementation Agreement was developed by the Frame Relay Forum. It serves as a basis for standards activities in this area.) Many carriers have begun deploying NNI connections among themselves, allowing customers to reap the benefit of a better managed network in those cases where their DLCs must traverse more than one frame relay carriers network. (Network managers familiar with X.25 services can think of the NNI as being similar in concept to the X.75 interface.) New activity in this arena includes NNI connections at DS-3 (45M bps) and smart interfaces, which automatically provide connectivity and enhance manageability between carrier networks. ISDN Access to Frame Relay A new method for accessing frame relay services came to the forefront in late 1995: ISDN access to frame relay. Although it is most likely to initially provide switched access to frame relay PVC connections (as opposed to SVCs, which are still not provisioned by any of the carriers), ISDN is being reborn in the US market because of its potential for providing frame relay and Internet access. For those new to packet switching, frame relay switched virtual circuits (discussed further in the next section) are akin to X.25 SVCs. Switched access to services, including frame relay, differs from SVC service in that switched access represents a dial connection to attach to some service, which can be based on PVCs, SVCs, or some other dedicated service. The switched connection can be maintained for as long as the user requires. If the tariff for the switched service does not bill by the minute for the users usage pattern, the user may choose to leave the connection up all the time. Frame relay SVCs, on the other hand, are virtual circuits that are dynamically initiated, then torn down on a connecting frame relay link. ISDN-frame relay internetworking is illustrated in Exhibit 3-4-5. In this exhibit, remote sites dial into the frame relay service and bring up frame relay on a B channel. The carrier takes care of the internetworking between the ISDN and frame relay services (e.g., by using the ANI of the calling party or by assigning unique ISDN numbers for customers to dial into).
In addition to the benefit of new, lower-cost ISDN services for access, this hybrid approach takes advantage of frame relay DLCs to support many simultaneous connections into the host or server site. (Whereas ISDN would limit the user to 23 or 30 simultaneous connections, frame relay can practically support hundreds, depending on traffic load.) Because there is no standard at this time for splitting frame relay over multiple trunks, to get more than 64K bps out of the dialup connection, users must employ data compression within the frame relay data stream or use alternative transport, such as multilink point-to-point protocol over leased lines or ISDN. Not using frame relay would, however, potentially negate the benefit of support of many simultaneous connections to the host or server site. Frame Relay SVCs: Switched Cells Frame relay SVCs are akin to X.25 SVCs in that they are connections initiated by the user, then torn down after the required data has been sent. Though frame relay SVCs were defined along with the initial standards, they were not implemented by early vendors and initial carriers of frame relay, mostly because of low user demand for SVCs. Most vendors intend to deliver frame relay SVC capability. The big question about frame relay SVCs at this time remains, how will the carriers (vendors) price the service (feature)? There are two likely scenarios:
Frame Relay Multicast Frame relay multicast refers to the two-way communications between many parties. In the context of the FRFs Multicast IA, the term refers to the multicast server model found in the ITU-TSS X.6 definition. One-way (i.e., broadcast), two-way, and N-way configurations are supported. As shown in Exhibit 3-4-6, in two-way communications, the recipients of information can feed back responses to the sender. The advantage of N-way communications is that all sites in the multicast group are logically connected, but need to send data only once for it to be received by the whole group.
It is anticipated that multicast service will gain favor for LAN internetworks (e.g., for use in routing or service updates) and for information delivery applications (e.g., stock quotes and news wires). The latter set of applications may be limited to private networks, as the organizations requiring them usually prefer to retain maximum control of data transfer and integrity. Currently, few vendors have implemented this feature, and no carrier offerings were available at the time of publication. Frame Relay Compression With the increasing popularity of data compression, as seen in modems, stand alone data compressors, compressed voice, IP header compression, and compressed video, it is anticipated that data compression over frame relay will become more popular. Compression allows users to get more for less by getting more data through a frame relay service at a given committed information rate or CIR (i.e., price). The Frame Relay Forum issued an Implementation Agreement for compression of frames over a frame relay service or network in early 1996. The technique used maintains compatibility with public frame relay service offerings by only compressing user data destined for the payload portion of the frame relay frames and not the header and trailer sections, which are required for addressing, control, and error checking (and therefore need to be left unaltered). Exhibit 3-4-7 illustrates data compression over frame relay.
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |